Internet Info 1994 March/Internet Info CD-ROM (Walnut Creek) (March 1994).iso/inet/ietf/bgpdepl/bgpdepl-minutes-93mar.txt

Text File | 1993-05-17 | 13KB | 309 lines

CURRENT_MEETING_REPORT_

Reported by Matt Mathis/PSC

Minutes of the BGP Deployment Working Group (BGPDEPL)

Administrivia

A question of venue was discussed, but not settled.  A hand vote
indicated the majority of those present were planning to attend the
Amsterdam meeting.  However, several of the key players would be unable
to attend.  There was also a question about whether an additional
meeting was needed before the next IETF. This question was deferred
pending organizational changes.

Later during the meeting it was observed that most of the configuration
discussion was not really BGP related, but more apropos of the original
``Internet Working Group (IWG)'', which was tasked with fostering sanity
in topology, routing policy, and configuration databases.  It is
interesting to note that the original BGP1 arose out of the IWG.

It was suggested that the IWG be reconstituted, and that the BGP
Deployment Working Group be folded in as one of its key tasks.

Vendor Reports


   o ANS/NSFnet/GATED.
     Dennis Ferguson reported that BGP4 is working in a test mode.  He
     also reported that new IGP code is under development.  This new
     code is needed to interoperate with the existing routed code in the
     backbone.

   o Cisco.
     Paul Traina indicated that BGP4 is still under development.  The
     development effort has been hit with some pretty significant delays
     and is going to be late.  BGP4 was not approved for inclusion into
     9.21, so there will be a special software release based upon 9.21
     with BGP4 support added.  This release will be available for
     testing and limited deployment before 9.21 has completed beta
     cycle.  The BGP4 special release should be ready for general
     availability near 9.21 FCS (no date available).  [This is an
     updated report to make it more accurate (for the worse).]

   o 3COM.
     Nagaraj Arunkumar expects to support BGP4 in release 6.2 due
     sometime early this fall.

   o Wellfleet.
     John Krawczyk anticipates rolling out BGP4 support this summer.


                                   1





   o Telebit Communications.
     Peder C. Norgaard reports that EUROPAnet is in the process of
     deploying BGP3 with no current plans for BGP4 deployment.


CIDR core plans (Alternet, CIX, EBone, NSFnet/ANS, NSI, PSI, Sprint)

As there appeared to be a critical mass of people interested in the BGP4
deployment who were also attending DC INTEROP, Claudio Tolpocic convened
a meeting to update plans.  The Minutes for this meeting are available
in the usual IETF directories as draft-ietf.bgpdepl-minutes-feb93-00.txt
(even though the meeting took place in March!).  That meeting was also
summarized for the Group with clarifications and expansions.

There was quite a bit of discussion concerning the deployment plan.  It
now looks like this:


  1. Start deploying BGP4 code as soon as possible.  It now appears that
     this may be delayed to as late as June.  The goal here is just to
     verify that the code works.  Exercise no new features of the
     protocol in the production Internet.

  2. NSI (or some alternative) starts announcing one aggregated network.
     This step has been split into two pieces:  2a) Initially announce
     an aggregated test network (assigned but non-production).  After
     verification that it is propagating properly to the rest of the
     core, 2b) aggregate ONE site (several production class C networks),
     and verify correct interoperability with the rest of the Internet.

  3. Additional CIDR core members start aggregating networks, first with
     test network and then with one production site each.
     Steps 2 and 3 can be partially overlapped as long as there are no
     adverse side effects of the announced aggregated nets, and that the
     selected aggregated sites can make arrangements to reach any
     portion of the Internet not yet supporting CIDR.

  4. Aggregation is officially ``turned on'' in the Internet.  This is a
     pseudo flag day because all sites requiring full routing tables
     must be either running BGP4 or must have made alternative
     arrangements (e.g., default routing).  Aggregation should be phased
     in incrementally (a few sites at a time) and continue to be
     restricted to the site level (aggregate only multiple class C
     networks at one site).  Aggregation of larger blocks of networks
     requires better solutions to some configuration management issues.
     Particularly mixed traffic types, etc., (e.g., AUP/non-AUP,
     multi-homed sites).

  5. Think....


At this point there was a discussion of a number of side issues.  Tony

                                   2





Hain of ESnet indicated that he was not sure what would happen in the
early phases, he would not be ready to support BGP4 by June.  ESnet may
have to use default routing to survive.

Paul Traina of cisco mentioned the possibility of adding something to
statically manage ``controlled de-aggregation'' using access lists and
last resort approach to CIDR. Dennis Ferguson quiped that he would
probably add something to gated in that case since ``gated should be
able to do anything the cisco can do''.

It was generally agreed that another meeting is need before step 4.  It
is unclear at this time if there would be contention and a real flag
day.  Hopefully all seven members of the CIDR core would either be fully
BGP4 or have made peace with default routing well in advance of step 4,
such that its precise timing is unimportant.  If there is a contentious
straggler, the community will eventually be forced to choose a flag day
over their protests.

The Group decided not to attempt to place precise dates on the schedule.
The members of the CIDR core are progressing as fast as possible, and
are well coordinated among themselves.  The schedule has already slipped
by about two months from where we projected at the DC IETF (in
November).

The next Regional-Techs meeting was mentioned as a possibility for
another BGP deployment Working Group meeting.  It is tentatively
scheduled for May or June in Washington, DC. Matt felt that this would
be a little too early.

CIDR Configuration Issues

There is some controversy over how to do global configuration checking.
In addition, how can we one ensure topology matches policy?

Mark Knopper of Merit presented a preliminary plan for aggregation
support in the NSFnet.  This support would:


  1. Accept aggregate routes from a midlevel, or
  2. Would accept site routes from a midlevel, and aggregate on the
     midlevels behalf.


A strawman database format had netprefix and length, source (aggregating
router) AS, and a destination AS list as components.  This proposal is
documented in the ``Inter-domain Routing Policy Description and
Sharing'' Internet-Draft written by Yun, Yu, Chen and Rekhter
(draft-yu-rpd.00.txt).  This presentation resulted in a suggestion to
split the single view into two views keyed on source AS. There was quite
a bit of discussion on where and how to split this to best support
debugging connectivity problems.



                                   3





Matt Mathis argued fairly strongly for aggregation being controlled by
the site owning the networks.  The argument is that configuration
control is far easier to manage if it is local.  Sue Hares felt fairly
strongly that central management is better.  Matt did concur that it is
a feature that Merit will have the capabilities to aggregate routes on
behalf of regionals who cannot, but would like to.

The representatives from RIPE pointed out that the existing U.S.
databases, including the current Merit configuration database and the
above proposal are not adequate to solve international routing problems.
In particular none can be used to determine which backbone (CIDR core
member) is the preferred path to a given U.S. network.  Consider for a
moment several sites with external connectivity to both NSFnet and PSI.
Each site may prefer one or the other for various reasons including
differing bandwidth, AUP, etc.  This is further complicated because the
ANS AS path does not reveal if the connection is ``blessed'' for non-NSF
AUP traffic.  Ideally the traffic from Europe could be routed solely on
the basis of ASpath but essential information is missing.  Alternatively
there should be a way to glean from our configuration databases which
backbone the site prefers, but again there is not.

Global Configuration Issues

Daniel Karrenberg presented the RIPE efforts in the Global configuration
database area.  He indicated the real focus of this effort was to
provide a tool their operators could use.  This database also contains
enough information o allow someone to compile suitable router network
configuration files.  It is documented as ``Representation of IP Routing
Policies in the RIPE Database'', and is available from the RIPE
repositories:  ftp.ripe.net:ripe/docs/ripe-docs/ripe-81.[txt,ps].

Things the RIPE effort cannot do include an inability to process and
propagate policies information on transit networks.  It cannot use
unpublished AS's, and it does nothing to solve the ``half baked'' AS
problem, outside of pointing out inconsistencies.

Closing Remarks

The sense of urgency came form concerns about configuration management
and database issues.  Although there is still a lot of work to be done
to complete the BGP4 roll out, it seems to be a fairly well understood
problem except for configuration management.  CIDR and BGP4 do impose
some new requirements on the databases but the majority of the issues
center around topology and AUP enforcement.  For these reasons it makes
sense to broaden the scope of this Working Group from just BGP
deployment to the wider task of fostering sanity in topology, routing
policy, and configuration databases.

Thanks to Robert Reschly and Gene Hastings for taking meeting notes.

Attendees


                                   4





Nagaraj Arunkumar        [e-mail]
William Barns            [e-mail]
Tony Bates               [e-mail]
Jordan Becker            [e-mail]
David Bolen              [e-mail]
Rebecca Bostwick         [e-mail]
Jeffrey Burgan           [e-mail]
Robert Calderon          [e-mail]
Henry Clark              [e-mail]
Robert Collet            [e-mail]
Tom Easterday            [e-mail]
Stefan Fassbender        [e-mail]
Mark Fedor               [e-mail]
Dennis Ferguson          [e-mail]
Vince Fuller             [e-mail]
Tony Hain                [e-mail]
Martyne Hallgren         [e-mail]
Eugene Hastings          [e-mail]
Roland Hedberg           [e-mail]
Ittai Hershman           [e-mail]
Jeffrey Honig            [e-mail]
Laurent Joncheray        [e-mail]
Matthew Jonson           [e-mail]
Dan Jordt                [e-mail]
Daniel Karrenberg        [e-mail]
John Krawczyk            [e-mail]
Padma Krishnaswamy       [e-mail]
Frank Liu                [e-mail]
Daniel Long              [e-mail]
Peter Lothberg           [e-mail]
Glenn Mackintosh         [e-mail]
Jamshid Mahdavi          [e-mail]
Bill Manning             [e-mail]
Jun Matsukata            [e-mail]
Daniel McRobb            [e-mail]
Dennis Morris            [e-mail]
Peder Norgaard           [e-mail]
David O'Leary            [e-mail]
Andrew Partan            [e-mail]
Brad Passwaters          [e-mail]
Michael Patton           [e-mail]
Willi Porten             [e-mail]
Selina Priestley         [e-mail]
Yakov Rekhter            [e-mail]
Robert Reschly           [e-mail]
Tony Richards            [e-mail]
Vilson Sarto             [e-mail]
John Scudder             [e-mail]
Paul Serice              [e-mail]
Kim Smith                [e-mail]
Bernhard Stockman        [e-mail]
Roxanne Streeter         [e-mail]
John Tavs                [e-mail]
Marten Terpstra          [e-mail]

                                   5





Paul Traina              [e-mail]
Curtis Villamizar        [e-mail]
Jack Waters              [e-mail]
Linda Winkler            [e-mail]
Cathy Wittbrodt          [e-mail]
Paul Zawada              [e-mail]



                                   6